Using the Public Transport program
This section discusses useful information for using the Public Transport program. Topics include:
Estimating demand matrices
You can use Cube Analyst to estimate public transport demand matrices. Cube Analyst uses screenline count data to update a "prior" matrix. Confidence levels determine how much each input influences the estimation process. See Cube Analyst Reference Guide for detailed information about the methods used.
Matrix estimation requires an intercept file, which provides data on routes crossing the defined screenlines for each origin-destination pair. A run of the Public Transport program produces the intercept file.
Screenline data files specify the links that compose each screenline and contain associated data, such as link counts and confidence levels. Confidence levels reflect the accuracy of count data and affect the weighting during the estimation process. You can create a screenline file with:
-
Cube, or text-file editors, and read the file in to the Public Transport run
-
Public Transport run, based on data values stored in the input network
Link variables in the input network contain the screenline number (zero if the link is not part of a screenline), link count, and confidence level.
For a Public Transport run to produce matrix estimation data, the script must specify a FILEO INTERCEPTO command, along with either a FILEI SCREENLINEI or a FILEO SCREENLINEO command. Alternatively, the software may save just a screenline output file without performing any route evaluation.
To configure the intercept file to contain only transit use of the links, or all demand (that is, transit plus nontransit use of all links), use the MEUSESNT keyword on PARAMETERS and FILEO SCREENLINEO commands.
Defining input and output files
You define input and output files for the Public Transport program with control statements FILEI and FILEO. These are present in the main script file.
Use control statements to define input and output data items (that is, LINE, MODE, OPERATOR, and NTLEGS). These are usually contained in files defined by FILEI and FILEO, and not in the script file.
All control statements available in the Public Transport program are described in Control statements. This section shows which files contain which data items.
Linking Highway and Public Transport models
In studies that model both highway and transit demand, you can link the two models.
Transit vehicles travel through junctions and take some of the junction capacity. For networks with congestion, a typical highway model estimates delays on links and at junctions. Link travel times include link delays, and trip time also includes junction delays. Junction delays can affect transit vehicles, though provisions like bus-only lanes can reduce or eliminate such delays at particular locations.
Cube Voyager can export junction delay data from Highway program runs, and include these delays in the run times of transit lines. However, because Highway assignment does not support turn-based preloads, Cube Voyager cannot import transit-vehicle turn volumes from Public Transport to Highway.
The Highway program can export delays for turning movements to a TURNPENO file. The Public Transport program can then read this file. The Public Transport program calculates a line’s travel times using TRANTIME (a global parameter that represents link travel times), junction delays, link delay, and dwell time values. TRANTIME and junction delays are network components, and delay and dwell time are line components.
When junction delays are included, transit-line run times are influenced by the highway network’s congestion levels. To model bus-only lanes or other provisions designed to reduce transit-line delay at junctions, you can limit the delay at a junction by defining a link variable that specifies an upper limit for delay on the approach link to a junction.
LINE definitions can include RUNTIME, RT, or NNTIME keywords, which provide control values. The program scales the line’s travel times up or down to match these control values. You might use control values in base-year models to ensure that the line’s travel time matches an expected value.
For forecast years, when you do not know the line’s travel time, you cannot code the time as part of the line. Instead, the program determines travel times with an incremental approach. The program calculates the line’s travel times for the base year, and compares these times to the control values to generate scaling factors for the increase or decrease in travel times. The program applies these factors and the forecast-year junction delays to compute the line’s travel times in the forecast year. Because the program does not scale these travel times to control totals, any changes reflect increases and decreases in junction delay along the route. The program applies scaling to link travel times and delay values; the program does not scale dwell times and junction delays. The method uses two sets of TURNPENI data, each with its own MAXDELAY variable (to reflect possibly different bus-lane provisions each year).
Typically, modeled stops are close to a junction node. Therefore, the program adds the entire junction delay to the travel time of the link approaching the modeled junction.
You might model turning delays at a transit line’s last node. The program accounts for such delays as occurring before the line reaches its final stop, even though the vehicle does not pass through the node. The program adds that node’s lowest turning delay to the travel time along the final link.
You should configure the model to read the TURNPENI file at the same time as the LINEI files. When reading LINE data from a network file, the program has already calculated link travel times and cannot amend turn penalties.
The Public Transport program requires a network that provides the basic infrastructure over which public transport services operate— zones, nodes/stops, links. This network can contain any node and link attributes you choose. Possible sources of the network include:
-
Network program, produced specifically for modelling a public transport system
-
Existing highway network produced by the Network or Highway programs
-
Public Transport program, in which case only the network information is used (the public transport element is discarded)
The network must provide basic link attributes that support the Public Transport program’s modelling functions: link distance, and walk and transit times or speeds.
Link distance is required (specified by LI.DISTANCE or another variable from which distance can be derived). The program uses link distance to calculate link times when you provide only speeds, to skim distance from routes, and to calculate fares for distance- based fare models.
Subsequent sections in this topic offer guidance on how to code transit and nontransit times and/or speeds in the network:
Transit times/speeds
The Public Transport program requires a base transit time for links that public transit lines traverse. This is supplied to the program with PARAMETERS TRANTIME. (You can factor each line’s base link- time in a variety of way, as described in LINE.)
You can use different techniques to specify a link’s transit time. Possible techniques include:
-
Set a link’s transit time to the congested time resulting from a highway assignment: TRANTIME = LI.TIME_CONGESTED (assuming the links contain a variable named TIME_CONGESTED).
-
Create a network variable that stores transit speeds with the Network program.
(If the highway network stores public transport links, you can exclude those links from highway assignments by setting those links’ path value to a negative value and their capacity to 0.)
-
Set array(s) of working link values in the LINKREAD phase and use those arrays in the TRANTIME expression.
For example:
PHASE=LINKREAD if (link condition...) LW.TTIME = LI.DISTANCE*60/LI.SPEED * 1.2 else LW.TTIME = LI.DISTANCE *60 / LI.SPEED endif ENDPHASE PARAMETERS TRANTIME=LW.TTIME
-
TRIPS users only. Input the TRIPS link records directly to the Network program to create a Cube Voyager network. The Network or Public Transport programs can derive transit and nontransit link times from the link record’s link-type field and the LTYP data in the lines file. See :Example 2: Preparing a public transport network from TRIPS link data.
Nontransit times/speeds
You can develop nontransit legs outside the Public Transport program, inside the Public Transport program, or some combination. Regardless of the process, you must use GENERATE statements within the DATAPREP phase to develop a nontransit network.
When developing the nontransit network outside the Public Transport program, you must ensure that you use costs—perceived or actual—consistent with the cost components that the route- enumeration and route-evaluation processes use.
Keywords in the GENERATE statement set the method for obtaining nontransit legs. However, you might need to precede the GENERATE statement with a script that manipulates link attributes. As in the LINKREAD phase, you can loop through all the links in the network and set desired link values.
Example:
PHASE=DATAPREP
LINKLOOP
if(link condition...)
LW.NTCOST = LI.DISTANCE * 1.6
else
LW.NTCOST = LI.TIME*3.8
endif
ENDLINKLOOP
GENERATE COST=LW.NTCOST * 2.5, EXCLUDE=(LW.NTCOST > 100)
ENDPHASE
Generating nontransit access and egress legs
The GENERATE statement is a powerful and flexible tool that generates the components of the nontransit network—access, egress, and transfer legs. However, misuse can generate unnecessary legs, resulting in poor quality routing.
Example 1: Drive-walk nontransit legs
Consider the routes from zone 1 to zone 11 in the network shown. Travellers access the transit system through nontransit legs generated with two GENERATE statements, for modes 1 (walk) and 2 (drive).
NT LEG=1-3967 MODE=2 COST=2.03 DIST=2.03 ONEWAY=T XN=4227 4006 4007 3963 3965 3966 NT LEG=1-4000 MODE=2 COST=1.66 DIST=1.66 ONEWAY=T XN=4005 4004 15646 4003 15647 3961 NT LEG=1-4143 MODE=2 COST=3.20 DIST=3.20 ONEWAY=T XN=4226 4267 4266 4265 4302 4303 4301 4144 4773 NT LEG=1-4227 MODE=1 COST=12.96 DIST=0.27 ONEWAY=T NT LEG=1-4263 MODE=2 COST=3.87 DIST=3.87 ONEWAY=T XN=4005 4004 15646 4003 15647 3961 4000 3999 3998 3997 9420 9419 3996 9423 3993 3992 9810 3991 NT LEG=1-4276 MODE=2 COST=2.66 DIST=2.66 ONEWAY=T XN=4268 4269 4270 4271 15687 8710 8709 4273 4274 NT LEG=1-4309 MODE=2 COST=2.12 DIST=2.12 ONEWAY=T XN=4268 4269 4307 4306 4308 NT LEG=1-4322 MODE=2 COST=3.39 DIST=3.39 ONEWAY=T XN=4268 4269 4270 4271 15687 8710 8709 4273 4315 4314 4316 4319 NT LEG=1-4386 MODE=2 COST=3.40 DIST=3.40 ONEWAY=T XN=4268 4269 4307 4306 4308 4309 4774 4349 4775
Travellers egress from the public transport system to zone 11 with the nontransit legs reproduced below, generated by a GENERATE statement. .. code-block:
NT LEG=4276-11 MODE=1 COST=3.36 DIST=0.07 ONEWAY=T NT LEG=4278-11 MODE=1 COST=14.40 DIST=0.30 ONEWAY=T XN=4276
The routing algorithms only recognize routes that have an access leg followed by pairs of transit and nontransit legs, the last being the egress leg. Although a nontransit-only route, 1->4276->11 exists, the algorithm will not enumerate that route.
The all-or-nothing process, which marks base times for the route- enumeration spread, finds that 1->4276 is the best access leg to the public transport system for zone 11. Because travellers cannot cannot walk directly to 11 from 4276, they ride a transit line to 4278 and walk to 11 from there. (Where transit alternatives are either not available or not feasible, the process will find no routes between the two zones.)
Because the program found a route, even a nonsensical one, the program finds base times at nodes and enumerates and evaluates routes.
REval Route(s) from Origin 1 to Destination 11 1 -> 4322 4322 -> 4280 -> 4280 lines AM4L5 AM4L6- AM4L18 4280 -> 4276 -> 11 lines AM4L12 AM4L89- Cost= 30.8287 Probability=0.2803 1 -> 4322 4322 -> 4325 -> 4325 lines AM4L5 AM4L6- AM4L18 4325 -> 4276 -> 11 lines AM4L12 AM4L89- Cost= 30.83 Probability=0.2803 1 -> 4276 4276 -> 4278 -> 11 lines AM4L12- AM4L89 Cost= 31.42 Probability=0.0071 1 -> 4276 4276 -> 4280 -> 4280 lines AM4L12- AM4L89 4280 -> 4276 -> 11 lines AM4L12 AM4L89- Cost= 34.98 Probability=0.0959 1 -> 4322 4322 -> 4276 -> 11 lines AM4L12 AM4L89- Cost= 19.62 Probability=0.3364
The fourth route in the list accesses and egresses the transit system at node 4276 and takes a transit line in between, raising questions about the quality of the evaluated routes. Rather than being an algorithmic problem, this arises due to the quality of the input data. In this case, if you allow drive access from zone 1 to 4276, then you should consider generating a drive-walk nontransit-only route between zones 1 and 11. Otherwise, remove the drive accesses and connect zone 1 to the transit system only with walk legs.
Removing routes that access and egress the transit system at the same node would alleviate just one symptom rather than the underlying cause.
A good nontransit network is essential for identifying good quality routes. You develop a nontransit network through an iterative process, validating and refining the network produced by the GENERATE statements over a few cycles.
Some useful GENERATE keywords to control the excessive generation of nontransit legs are:
Considering nontransit-only routes
A route in the Public Transport program consists of an access leg, and one or more pairs of transit leg bundles and nontransit legs, the last of which is the egress leg. Thus, nontransit-only routes never get enumerated, and zones may appear unconnected when they are not.
Even when nontransit-only routes are not of interest, they have to be dealt with. Nontransit-only routes might be much faster than expected transit routes. If the cost difference between the two is outside the range of the route-enumeration SPREAD, the program will not enumerate the transit routes either. Thus the program will not connect zones by transit, for no apparent reason.
Example 1: Drive-only route
This diagram shows two walk (MODE=11) access legs and one drive (MODE=12) access leg that two GENERATE statements generate. No drive-drive routes are generated.
NT LEG=81-1092 MODE=11 COST=19.20 DIST=0.40 ONEWAY=T XN=1094 NT LEG=81-1104 MODE=11 COST=7.68 DIST=0.16 ONEWAY=T NT LEG=81-1109 MODE=12 COST=1.41 DIST=0.47 ONEWAY=T VOL=430 VOLT=430 XN=1104
The transit time from 1109 to 1092 is just under a minute. Therefore, the all-or-nothing process determines that the best stop to access line MAIN is 1109.
The program generates several nontransit legs at 1109, including a drive egress:
NT LEG=1109-99 MODE=12 COST=1.53 DIST=0.65 ONEWAY=T XN=11081105
The best-cost route from 81->99 is to drive from 81 to 1109 and then to 99. However, because this is a nontransit-only route neither the all-or-nothing process nor the enumeration process will enumerate the route. Further, because the route is so much faster than any of the possible transit routes, the program will not enumerate the transit routes either, unless you define a very large route-enumeration SPREAD, which will result in an unnecessarily large route set for those zone pairs that genuinely connect with transit routes (most zone pairs in any study). Therefore, zones 81 and 99 will appear unconnected.
If you are not interested in nontransit-only routes, skims, and loads, you can leave such zone pairs unconnected. However, when validating a network, you might establish why zone pairs do not connect.
If, however, nontransit-only routes are required, then drive-only connections between zones should be generated:
GENERATE, COST=(li.DIST * 60) /li.OFFPSPD, MAXCOST[1]=5, NTLEGMODE = 14, FROMNODE=81, TONODE=99
This statement generates short drive-only routes between zones that cost 5 units or less.
NT LEG=81-99 MODE=14 COST=2.19 DIST=0.88 ONEWAY=T VOL=10 VOLT=10 XN=1094 1093 1092 1091 1090 1107
This route traverses links other than 81->1109 and 1109->99 and costs even less, making any transit-based routes even less competitive. However, because the NT statement identifies the drive-only route, the route-enumeration and route-evaluation processes enumerate that route:
REnum Route(s) from Origin 81 to Destination 99 81 -> 99 Cost=2.19 REval Route(s) from Origin 81 to Destination 99 81 -> 99 Cost= 2.19 Probability=1.0000
In this example, the transit routes are much slower than the drive- only one, and are only enumerated when SPREADFACT is 1.5. Although the program enumerates transit routes, the program only uses the drive-only route. The route-evaluation process discards the other routes because they cannot compete with the drive-only route.
REnum Route(s) from Origin 81 to Destination 99 81 -> 1109 1109 -> 569 -> 569 lines SMAIN 569 -> 1107 -> 99 lines SMAIN SMAIN Cost=58.95 81 -> 1109 1109 -> 1107 -> 99 lines SMAIN Cost=59.61 81 -> 99 Cost=2.19 REval Route(s) from Origin 81 to Destination 99 81 -> 99 Cost= 2.19 Probability=1.0000
You must carefully consider how to model short, fast nontransit- only routes when there are transit alternatives. Undetected, nontransit-only routes can result in poor quality routing as described in Generating nontransit access and egress legs.